U.S. Pat. No. 6,470,478 granted to Bargh, et al. describes a counting instrument designed to detect occurrences of a count event within a design entity during simulation of the digital circuit design. The counting instrument is utilized to monitor each instantiation of the design entity within the simulation model without the instrumentation entity becoming incorporated into the digital circuit design.
Specifically, as illustrated in FIG. 1 attached hereto, Bargh, et al. describe an instance 10 and an instance 11 of an instrumentation entity FXUCHK that are depicted to be performing monitoring on two instances 21a and 21b of an FXU entity. For each instantiation of FXU entity 21a and 21b, an instantiation 10 and 11 respectively, of FXUCHK is automatically generated. In a similar fashion, instrumentation entity FPUCHK 12, is instantiated to monitor FPU entity 22. Bargh et al. state that the automatic instantiation of instrumentation entities for each instance of a target entity is a significant advantage.
Bargh et al. further state that each instrumentation entity can monitor any signal within its associated target entity. In the example of FIG. 1, entity FXUCHK is depicted as monitoring a signal Q 72, a signal R 76, and a signal S 74 within each of instances 21a and 21b of the FXU entity. Signal Q 72, is a signal within the instances 25a and 25b of descendant entity A. Likewise, signal S 74 is a signal within descendant entity C which is within descendant entity B. Finally, signal R 76 occurs directly within FXU entity 21. An instrumentation entity may monitor any signal within a target entity or the target entity's descendent entities. However, signals outside the target entity cannot be monitored.
According to Bargh, et al., each instrumentation entity is connected by means of fail, count, and harvest signals to an instrumentation logic block 20. Instrumentation logic block 20 is generated automatically and contains logic for recording occurrences of each of the three event types. For the count events monitored in simulation model 29, a set of counters 21 are utilized to count the number of occurrences of each count event. In a similar manner, a set of flags 24 is utilized to record the occurrence of failure events. Finally, a set of counters 22 and flags 23 are combined and utilized to record the point at which a harvest event occurs and the fact that a harvest event occurred, respectively. Bargh et al. also state that in one embodiment a cycle number is captured and stored utilizing counters 22 and flags 23 to record a harvest event. The logic structures of instrumentation logic block 20 are created without direct intervention by the user.
Incorporated by reference herein in their entirety are the following references:
U.S. Pat. No. 5,920,490 granted to Peters on Jul. 6, 1999 and entitled “Integrated circuit test stimulus verification and vector extraction system.”
U.S. Pat. No. 5,544,067 granted to Rostoker, et al. entitled “Method and system for creating, deriving and validating structural description of electronic system from higher level, behavior-oriented description, including interactive schematic design and simulation”
Also well known in the art is the use of a bitmap to indicate the status of information being held in blocks of memory. Specifically, the bitmap indicates whether or not information that is temporarily held in a cache has been changed in main memory. For example, a bitmap may contain one bit for each block (e.g. 1 page) of main memory. Whenever any information stored within a memory block in main memory is changed, a bit corresponding to that memory block is “dirtied” (i.e. changed from valid to invalid) within the bitmap. Any future access to the temporarily held information in a cache requires fetching of the newly-updated information from the memory block in main memory because of the “dirtied” bit in the bitmap. After such an access the “dirtied” bit is cleared thereby to indicate that the temporarily-held information in the cache is now current (until information in main memory changes).
To the inventor's knowledge, such a bitmap has been used in the prior art only in the context of representing the status of information in each of a number of blocks in main memory that are contiguous with one another and homogenous in all respects. In such a bitmap, a first bit indicates the status of information in a first memory block, and a second bit indicates the status of information in a second memory block and so on. Such a prior art bitmap summarizes only the state of a single, homogenous, contiguous memory. Moreover, to the inventor's knowledge, the prior art teaches use of only a single bitmap of the type described above.
Also known in the prior art is the use of a dirty/polling bit associated with an emulated register/memory to indicate whether its value is changed. This prior art method is not efficient on polling the changed memories/registers. However, to have one polling bit associated with each monitored resource is inefficient. To poll for triggered resource, an application needs to go through polling bits one by one.
Some prior art implementations use a linked list to record all changed memories/registers. This prior art method is more efficient than the above-described prior art method, but not flexible, and not scalable. The linked list of these prior art implementations must be processed immediately after each simulation step and cannot be used for applications requiring multiple different kind of monitor devices for the same memory/register. To use a linked list to list all triggered resources is not flexible and not easy to adapt for multiple monitoring applications. The triggered linked list must be processed together. This prevents the possibility of having applications to poll for triggered resources at different moments. Also, the use of linked list is not efficient when a resource may get triggered multiple times before the application does the polling. Moreover, before a triggered resource can be added into the linked list, it must check if it has already been on the list to prevent duplication.
See also Chapter 3 entitled “The Buffer Cache” in a book entitled “The Design of the Unix Operating System”, Maurice J. Bach, Prentice-Hall, Inc. 1986, ISBN 0-13-201799-7 025, pp. 38–58. In this reference, Bach describes a similar scheme for maintaining a file system buffer cache.